re:Invent2015でのマイクロサービスに関するまとめと私見

AWS re:Invent 2015

#レポート

#AWS

丹内優紀

2015.10.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

丹内です。日本に戻ってきました。
今回参加したre:Invent 2015のうち、ECS/Lambda/マイクロサービスに関するブログが以下のものになります。

今回のre:InventではIoTやMobileHubの大型リリース、LambdaやKinesisのアップデートなどが熱かった影で、この「ECS/Lambda/マイクロサービス」のセッションも数が多く、どれも長蛇の列でした。

ECS/Lambda/マイクロサービス

ECS(EC2 Container Service)は、複数のDockerコンテナをEC2上で動かすことをサポートするサービスです。
Lambdaは、計算処理の単位でEC2を使うサービスです。
この2つは別のサービスで、re:Inventに参加するまでは特に関連を感じていませんでした。ECSはDockerコンテナを動かすという点ではElasticBeanstalkのDockerコンテナと似たようなものかなという印象でしたし、Lambdaは単純な処理を格安で実行できたりCloudFormationのラストワンマイルという印象でした。
なのでre:Inventが始まるまでは、特にECSやLambdaのセッションにここまで出ようとは思っていなかったですし、新しいサービスに関連するセッションがあったらそっちに行こうと思っていました。

しかし、Lambdaのセッションで以下の言葉を聞いてその意識が根底から変わります。

LambdaFunction is microservices without servers

以下のスライドを御覧ください。(レポート)ARC308: AWS Lambdaを使用している、サーバーのない企業:AWSによるストリーミングアーキテクチャー #reinventのスライドです。

EC2で動いているこれまでのアプリケーションは以下の様に表せます。1台のインスタンスに複数のサーバサイドアプリケーションが含まれています。

これがECS上のコンテナになったものが以下の図です。1つのコンテナに1つまたは関連するアプリケーションコードが入っていて、そのコンテナが1つのインスタンスに複数配置されています。

ここからコンテナとインスタンスの考え方を外したのが以下の図です。1コンテナ1アプリケーションコードを徹底していくと、コンテナ内は「Function」と呼べる小さな単位のコードになります。

現在のAWSでこれをどう実装するかというと、それがLambdaです。

つまり、LambdaはECSによるマイクロサービスを徹底して行った延長線上であって、アプリケーションコードの1つであるとも考えることができます。

実際にセッションを見て

ECS/Lambda/マイクロサービスと名前に付いているどの発表を見ても、Blueprintでも何でもなく、実際にやってみてどうだったかという事例に基づいたセッションでした。
聴講者が多かったあたりから「やりたいけどできていない」「興味はあるけど特にやってない、うまくいってない」という会社も多いのかなという印象ですが、しかし実際に商用環境での実績が出始めているということだと思います。

ECSからLambda、そしてその先へ

既存サービスからアプリケーションをいきなりLambdaに切り出すのは難しいと思います。しかし、例えば次の新規開発案件ではマイクロサービス化してECSで動かす、ということはできるかもしれません。
そうして作っているうちに「これLambdaにしてもいいかも」というサービスと、それを管理できるツールが出揃ったらLambdaFunctionに切り出して行くのが、一番現実的なのかなと思います。
さらに、もしかしたらそうして書いたLambda FunctionがAWSに正式に機能として実装されるかもしれません。そうなったらLambda Functionにデプロイしているサービスを削除して、依存サービスを書き換えれば完全に手がかからなくなるのでしょう。

実際にマイクロサービスをやるために

セッションにもあったのですが、マイクロサービスで作る上では非機能要件の実装が多くありそうでした。

12Factor
内部APIのスロットリングや認証
サービスごとにビルドパイプラインの管理

これらの要件は、自分でコードとして実装しなくてもAPI GatewayやECSを使って実現可能です。
AWSでできることは、自分でやらずにAWSでやったほうが良いです。

また、サービスディスカバリや設定の管理などは、NetflixのOSS群を使っても良いと思いました。
これらもAWSでできるとは思うのですが、私のようにマイクロサービスや分散アプリケーションを作った経験がないうちは、「そもそも何をすればよいかわからない」という状態からのスタートだと思います。その場合は先駆者に乗っかって経験を積んだほうがよいかもしれません。これらはSpring BootというJavaのフレームワークを使うのが良さそうです。

(レポート)BDT312: ポストサーバーの世界におけるアプリケーションモニタリング:データコンテキストが重要な理由 #reinventでもあったとおり、マイクロサービスのLambda化をする際の課題の1つとして、監視が挙げられます。デプロイや管理はJAWSフレームワークなどツールによって解決できそうですが、この分野は経験がモノを言うところもあり、実際にやってみないとわからないかなと思います。